1982 年，美国人蒂姆 · 伯纳斯 · 李为了方便世界各地的物理学家能够进行合作研究以及信息共享，创造了 HTML 语言。 1990 年它又发明了世界上第一个浏览器。
1991 年 3 月，它把这个发明介绍给了一起在 CERN 公司工作的朋友，当时网页浏览器被 CERN 公司在世界各地的成员用来浏览 CERN 庞大的电话薄。
1993 年， NCSA 推出了 Mosaic 浏览器并迅速爆红，成为世界上第一个广泛应用的浏览器，推动着互联网迅猛发展。在随后的 5 年里， Netscape 和 Microsoft 两个软件巨头掀起了一场互联网浏览器大战。这场战争最后以 Microsoft 的 Internet Explorer 完胜告终，但它极大地推动了互联网的发展，把网络带到了千千万万普通用户面前。从 1993 年互联网工程工作小组（ IETF ）工作草案发布，到 1999 年 W3C 发布 HTML 4.01 标准， HTML 共经历过 5 个版本。如今的 HTML 不仅成为 Web 上最主要的文档格式，而且在个人及商业应用中都发挥着它的作用。
HTML 最早是从 2.0 版开始的，实际上并没有 HTML 1.0 版官方规范。 HTML Tags 文档可以算作 HTML 的第一个版本，但它却不是一个正式的版本。第一个正式版本 HTML 2.0 也不是出自 W3C 之手，而是由 IETF （ Internet Engineering Task Force ，因特网工程任务组）制定的，从第三个版本开始， W3C （ World Wide Web Consortium ，万维网联盟）开始接手并负责后续版本的制定工作。
20 世纪 90 年代， HTML 有过几次快速的发展。众所周知，那时构建网站是一项十分复杂的工程，浏览器大战曾令人头疼不已，市场竞争的结果就是各家浏览器里都塞满了各种专有的特性，都试图在专有特性上胜人一筹。当时的混乱程度不堪回首， HTML 还重不重要，或者它作为 Web 格式的前景如何，谁都说不清楚。
从 1997 年到 1999 年， HTML 的版本从 3.2 到 4.0 ，再到 4.01 ，经历了非常快的发展。问题是到了 4.01 的时候， W3C 的认识发生了倒退， W3C 并没有停止开发这门语言，只不过它们对 HTML 不再感兴趣了。在 HTML 4.01 之后， W3C 提出了 XHTML 1.0 的概念。虽然听起来完全不同，但 XHTML 1.0 与 HTML 4.01 其实是一样的。
这两个规范的内容是一样的，词汇表是一样的，所有的元素是一样，所有的属性也都是一样的，唯一不同的就是 XHTML 1.0 要求使用 XML 语法。也就是说，所有属性都必须使用小写字母，所有元素也必须使用小写字母，所有属性值都必须加引号，所有的标签都必须有结束标签，对 img 和 br 等孤标签，要使用自结束标签。
从规范本身的内容来看，本质是相同的，不同之处就是编码风格，因为浏览器读取符合 HTML 4.01 、 HTML 3.2 或者 XHTML 1.0 规范的网页都没有问题，对浏览器来说这些网页都是一样的，都会生成相同的 DOM 树，只不过用户更喜欢 XHTML 1.0 ，因为不少人认同它比较严格的编码风格。
到了 2000 年， Web 标准项目（ Web Standards Project ）的活动开展得如火如荼，开发人员对浏览器里包含的那些乱七八糟的专有特性已经忍无可忍了。当时 CSS 有了长足的发展，而且与 XHTML 1.0 的结合也很紧密， CSS+XHTML 1.0 可以算是最佳实践了。虽然 HTML 4.01 与 XHTML 1.0 没有本质上的区别，但是大部分开发人员接受了这种组合。专业的开发人员能做到元素全部小写，属性全部小写，属性值也全部加引号。由于专业人员起到了模范带头作用，越来越多的人也都开始支持这种语法。
XHTML 1.0 之后是 XHTML 1.1 ，只是小数点后面的数字变成了 1 ，而且从词汇表的角度看，规范本身没有什么新内容，元素、属性也都相同，唯一的变化就是必须把文档标记为 XML 文档。而在使用 XHTML 1.0 的时候，还可以把文档标记为 HTML 。
但是，这样做就带来很多问题：首先，把文档标记为 XML 后， IE 浏览器不能处理。当然， IE9 及其以上版本是可以处理的。作为全球领先的浏览器， IE 无法处理接收到的 XML 文档类型的文档，而规范又要求以 XML 文档类型来发送文档，这对于广大用户来说，是一件很痛苦的事情。
所以说 XHTML 1.1 有点脱离现实，而用户不想把文档以 XML 格式发送给那些能够理解 XML 的浏览器，则是因为 XML 的错误处理模型。 XML 的语法，无论是属性小写，元素小写，还是始终要给属性值加引号，这些都没有问题，但 XML 的错误处理模型却是这样的：如果解析器遇到错误，停止解析。如果把 XHTML 1.1 标记为 XML 文档类型，假设用 Firefox 打开这个文档，而文档中有一个符号没有正确编码，就算整个页面中只有这一处错误，浏览器也会死掉，用户将看不到任何网页内容。根据 XML 规范，这样处理是正确的，对 Firefox 而言，遇到错误就停止解析，并且不呈现其它任何内容是严格按照 XML 规范处理的。因为它不是 HTML ， HTML 根本没有错误处理模型，但根据 XML 规范，这样做没错。这就是为什么人们不会把文档标记为 XML 的另一个原因。
接下来，新的版本是 XHTML2 ，但是这个版本并没有完成。从理论的角度来说， XHTML2 是一个非常好的规范。如果所有人都同意使用的话，也一定是一个非常好的格式。只不过，它还不够实际。
首先， XHTML2 仍然使用 XML 错误处理模型，用户必须保证以 XML 文档类型发送文档；其次， XHTML2 中有意不再向后兼容已有的 HTML 的各个版本，甚至曾经讨论过废除 img 元素，这对每天都在做 Web 开发的人来说确实有点难以接受，理论上分析，使用 object 元素可能会更好。
因此，无论 XHTML2 在理论上是多么完美的一种格式，却从未有机会付诸实践。之所以难以将其付诸实践，就是因为开发人员永远不会支持它，它不向后兼容。同样，浏览器厂商也不会支持它，必须要保证浏览器向后兼容。为什么 XHTML 1.1 没有像 XML 那样得到真正广泛地应用？为什么 XHTML2 从未落到实处？因为它违反了一条设计原理，这条设计原理就是著名的伯斯塔尔法则：发送时要保守，接收时要开放。
接收的时候要开放，而这也正是 Web 得以构建的基础。开发浏览器的人必须敞开胸怀，接收所有发送给浏览器的东西，因为它们过去一直都在接收那些不够标准的东西， Web 上的很多文档都不规范，但那正是 Web 发展的动力。从某种角度讲， Web 走的正是一条混沌发展之路，虽然混沌，却非常美丽诱人。在 Web 上，格式不规范的文档随处可见，如果所有人都能够写出精准的 XML ，所有文档的格式都十分正确，那当然好，可是那不现实。
作为专业人士，在发送文档的时候应该保守一些，尽量采用最佳实践，尽量确保文档格式良好，但从浏览器的角度说，它们必须以开放的姿态去接收任何文档。
XHTML 1.1 和 XHTML2 都使用 XML 错误处理模型，但这个错误处理模型太苛刻了，它不符合 " 接收时开放 " 这个法则，遇到一个错误就停止解析怎么能叫开放呢？我们只能说它与伯斯塔尔法则是对立的。
在 20 世纪末期， W3C 琢磨着改良 HTML 语言 "HTML 也许还可以更长寿一点，只要把我们放在 XHTML 上的时间和精力拿出一部分来，就可以提升一下 HTML 中的表单，可以让 HTML 更接近编程语言，就可以让它更上一层楼。"
于是，在 2004 年 W3C 成员内部的一次研讨会上， Opera 公司的代表伊恩 · 希克森（ Ian Hickson ）提出了一个扩展和改进 HTML 的建议。它建议新任务组可以跟 XHTML2 并行，但是在已有 HTML 的基础上开展工作，目标是对 HTML 进行扩展。但是 W3C 投票表示反对，因为 HTML 已经死了， XHTML2 才是未来的方向。然后， Opera 、 Apple 等浏览器厂商以及其它一些成员脱离了 W3C ，它们成立了 WHATWG （ Web Hypertext Applications Technology Working Group ， Web 超文本应用技术工作组），这就为 HTML5 将来的命运埋下了伏笔。
WHATWG 决定完全脱离 W3C ，在 HTML 的基础上开展工作，向其中添加一些新东西。这个工作组的成员里有浏览器厂商，因此它们可以保证实现各种新奇、实用的点子。结果，大家不断提出一些好点子，并且逐一做到了浏览器中。
WHATWG 的工作效率很高，不久就初见成效。在此期间， W3C 的 XHTML2 没有什么实质性的进展。在 2006 年，蒂姆 · 伯纳斯 · 李（ Tim Berners-Lee ）写了一篇博客反思 HTML 的发展历史， " 你们知道吗？我们错了。我们错在企图一夜之间就让 Web 跨入 XML 时代，我们的想法太不切实际了，是的，也许我们应该重新组建 HTML 工作组了。 " 。
W3C 在 2007 年组建了 HTML5 工作组。这个工作组面临的第一个问题，毫无疑问就是 " 我们是从头开始做起呢，还是在 2004 年成立的那个叫 WHATWG 的工作组既有成果的基础上开始工作呢？ " 答案是显而易见的，它们当然希望从已经取得的成果着手，以之为基础展开工作。于是它们又投了一次票，同意在 WHATWG 工作成果的基础上继续开展工作。
第二个问题就是如何理顺两个工作组之间的关系。 W3C 这个工作组的编辑应该由谁担任？是不是还让 WHATWG 的编辑，也就是现在 Google 的伊恩 · 希克森来兼任？于是它们又投了一次票，赞成让伊恩 · 希克森担任 W3C HTML5 规范的编辑，同时兼任 WHATWG 的编辑，更有助于新工作组开展工作。
这就是它们投票的结果，也就是我们今天看到的局面：一种格式，两个版本。 WHATWG 的网站上有这个规范，而 W3C 的站点上同样也有一份。
如果不了解内情，你很可能会产生这样的疑问： " 哪个版本才是真正的规范？ " 当然，这两个版本内容是一样的，基本上相同，但这两个版本将来还会分道扬镳。现在已经有分道扬镳的迹象了： W3C 最终要制定一个具体的规范，这个规范会成为一个工作草案，定格在某个历史时刻，而 WHATWG 还在不断地迭代，即使是目前的 HTML5 也不能完全涵盖 WHATWG 正在从事的工作。最准确的理解就是 WHATWG 正在开发一项简单的 HTML 或 Web 技术，因为这才是它们工作的核心目标。然而，同时存在两个这样的工作组，这两个工作组同时开发一个基本相同的规范，这无论如何也容易让人产生误解，误解就可能造成麻烦。
其实这两个工作组背后各自有各自的流程，因为它们的理念完全不同。在 WHATWG ，可以说是一种独裁的工作机制。伊恩 · 希克森是编辑，它会听取各方意见，在所有成员各抒己见，充分陈述自己的观点之后，它批准自己认为正确的意见。而 W3C 则截然相反，可以说是一种民主的工作机制。所有成员都可以发表意见，而且每个人都有投票表决的权利。这个流程的关键在于投票表决。从表面上看， WHATWG 的工作机制让人难以接受， W3C 的工作机制听起来让人很舒服，至少体现了人人平等的精神。但在实践中， WHATWG 的工作机制运行得非常好，这主要归功于伊恩 · 希克森。它在听取各方意见时，始终可以做到丝毫不带个人感情色彩。
从原理上讲， W3C 的工作机制很公平，而实际上却非常容易在某些流程或环节上卡壳，造成工作停滞不前，一件事情要达成决议往往需要花费很长时间。那到底哪种工作机制最好呢？最好的工作机制是将二者结合起来。而事实也是两个规范制定主体在共同制定一份相同的规范，这倒是非常有利于两种工作机制相互取长补短。
两个工作组之所以能够同心同德，主要原因是 HTML5 的设计思想。因为它们从一开始就确定了设计 HTML5 所要坚持的原则。结果，我们不仅看到了 HTML5 语言规范，也就是 W3C 站点上公布的那份文档，还在 W3C 站点上看到了另一份文档，也就是 HTML5 设计原理。